home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-mhsds-subtrees-03.txt < prev    next >
Text File  |  1993-07-08  |  11KB  |  417 lines
  1.  
  2.  
  3. Network Working                                             S.E. Kille
  4. Group                                                 ISODE Consortium
  5. INTERNET-DRAFT                                               July 1993
  6.                                                 Expires:  January 1994
  7.  
  8.           Representing Tables and Subtrees in the Directory
  9.  
  10.  
  11.  
  12. Status of this Memo
  13. This document is an Internet Draft.  Internet Drafts are working
  14. documents of the Internet Engineering Task Force (IETF), its Areas,
  15. and its Working Groups.  Note that other groups may also distribute
  16. working documents as Internet Drafts.
  17. Internet Drafts are draft documents valid for a maximum of six months.
  18. Internet Drafts may be updated, replaced, or obsoleted by other
  19. documents at any time.  It is not appropriate to use Internet Drafts
  20. as reference material or to cite them other than as a ``working
  21. draft'' or ``work in progress.''
  22.  
  23. Please check the I-D abstract listing contained in each Internet Draft
  24. directory to learn the current status of this or any other Internet
  25. Draft.
  26. Abstract
  27. This document defines techniques for representing two types of
  28. information mapping in the OSI Directory [1].
  29.  
  30.  
  31. 1.  Mapping from a key to a value (or set of values), as might be done
  32.     in a table lookup.
  33.  
  34. 2.  Mapping from a distinguished name to an associated value (or
  35.     values), where the values are not defined by the owner of the
  36.     entry.  This is achieved by use of a directory subtree.
  37.  
  38. These techniques were developed for supporting MHS use of Directory
  39. [2], but are specified separately as they have more general
  40. applicability.
  41.  
  42. This draft document will be submitted to the RFC editor as a protocol
  43. standard.  Distribution of this memo is unlimited.  Please send
  44. comments to the author or to the discussion group
  45. <mhs-ds@mercury.udev.cdc.com>.
  46.  
  47.  
  48.  
  49.  
  50. INTERNET--DRAFT             Representing Subtrees            July 1993
  51.  
  52.  
  53. 1  Representing Flat Tables
  54.  
  55. Before considering specific function, a general purpose technique for
  56. representing tables in the directory is introduced.  The schema for
  57. this is given in Figure 1.
  58. A table can be considered as an unordered set of key to (single or
  59. multiple) value mappings, where the key cannot be represented as a
  60. global name.  There are four reasons why this may occur:
  61.  
  62.  
  63. 1.  The object does not have a natural global name.
  64.  
  65. 2.  The object can only be named effectively in the context of being a
  66.     key to a binding.  In this case, the object will be given a
  67.     natural global name by the table.
  68.  
  69. 3.  The object has a global name, and the table is being used to
  70.     associate parameters with this object, in cases where they cannot
  71.     be placed in the objects global entry.  Reasons why they might not
  72.     be so placed include:
  73.  
  74.      o  The object does not have a directory entry
  75.  
  76.      o  There is no authority to place the parameters in the global
  77.         entry
  78.  
  79.      o  The parameters are not global --- they only make sense in the
  80.         context of the table.
  81.  
  82. 4.  It is desirable to group information together as a performance
  83.     optimisation, so that the block of information may be widely
  84.     replicated.
  85.  
  86. A table is represented as a single level subtree.  The root of the
  87. subtree is an entry of object class Table.  This is named with a
  88. common name descriptive of the table.  The table will be located
  89. somewhere appropriate to its function.  If a table is private to an
  90. MTA, it will be below the MTA's entry.  If it is shared by MTA's in an
  91. organisation, it will be located under the organisation.
  92.  
  93. The generic table entry contains only a description.  All instances
  94. will be subclassed, and the subclass will define the naming attribute.
  95. Two subclasses are defined:
  96.  
  97.  
  98. Kille                                  Expires:  January 1994   Page 1
  99.  
  100.  
  101.  
  102.  
  103. INTERNET--DRAFT             Representing Subtrees            July 1993
  104.  
  105.  
  106. _______________________________________________________________________
  107. table OBJECT-CLASS
  108.     SUBCLASS OF top
  109.     MUST CONTAIN {commonName}
  110.     MAY CONTAIN {manager}
  111.     ::= oc-table
  112.  
  113.  
  114. tableEntry OBJECT-CLASS
  115.     SUBCLASS OF top
  116.     MAY CONTAIN {description}                                       10
  117.     ::= oc-table-entry
  118.  
  119. textTableEntry OBJECT-CLASS
  120.     SUBCLASS OF tableEntry
  121.     MUST CONTAIN {textTableKey}
  122.     MAY CONTAIN {textTableValue}
  123.     ::= oc-text-table-entry
  124.  
  125. textTableKey ATTRIBUTE
  126.     WITH ATTRIBUTE-SYNTAX                                           20
  127.         caseIgnoreStringSyntax
  128.     ::= at-text-table-key
  129.  
  130. textTableValue ATTRIBUTE
  131.     WITH ATTRIBUTE-SYNTAX
  132.         caseIgnoreStringSyntax
  133.     ::= at-text-table-value
  134.  
  135. distinguishedNameTableEntry OBJECT-CLASS
  136.     SUBCLASS OF tableEntry                                          30
  137.     MUST CONTAIN {distinguishedNameTableKey}
  138.     ::= oc-distinguished-name-table-entry
  139.  
  140. distinguishedNameTableKey ATTRIBUTE
  141.     WITH ATTRIBUTE-SYNTAX
  142.         distinguishedNameSyntax
  143.     ::= at-distinguished-name-table-key
  144.  
  145.  
  146.  
  147. ____________________Figure_1:__Representing_Tables_____________________
  148.  
  149.  
  150.  
  151. Kille                                  Expires:  January 1994   Page 2
  152.  
  153.  
  154.  
  155.  
  156. INTERNET--DRAFT             Representing Subtrees            July 1993
  157.  
  158.  
  159. 1.  TextEntry, which define table entries with text keys, which may
  160.     have single or multiple values of any type.  An attribute is
  161.     defined to allow a text value, to support the frequent text key to
  162.     text value mapping.  Additional values may be defined.
  163.  
  164. 2.  DistinguishedNameEntry.  This is used for associating information
  165.     with globally defined objects.  This approach should be used where
  166.     the number of objects in the table is small or very sparsely
  167.     spread over the DIT. In other cases where there are many objects
  168.     or the objects are tightly clustered in the DIT, the subtree
  169.     approach defined in Section 2 will be preferable.  No value
  170.     attributes are defined for this type of entry.  An application of
  171.     this will make appropriate subtyping to define the needed values.
  172.  
  173. This is best illustrated by example.  Consider the MTA:
  174.  
  175.  
  176. CN=Bells, OU=Computer Science,
  177. O=University College London, C=GB
  178.  
  179. Suppose that the MTA needs a table mapping from private keys to fully
  180. qualified domain names (this example is fictitious).  The table might
  181. be named as:
  182.  
  183. CN=domain-nicknames,
  184. CN=Bells, OU=Computer Science,
  185. O=University College London, C=GB
  186.  
  187.  
  188. To represent a mapping in this table from ``euclid'' to
  189. ``bloomsbury.ac.uk'', the entry:
  190.  
  191. CN=euclid, CN=domain-nicknames,
  192. CN=Bells, OU=Computer Science,
  193. O=University College London, C=GB
  194.  
  195.  
  196. will contain the attribute:
  197.  
  198. TextTableValue=bloomsbury.ac.uk
  199.  
  200.  
  201. A second example, showing the use of DistinguishedNameEntry is now
  202. given.  Consider again the MTA:
  203.  
  204. Kille                                   Expires: January 1994   Page 3
  205.  
  206.  
  207.  
  208.  
  209. INTERNET--DRAFT             Representing Subtrees            July 1993
  210.  
  211. _______________________________________________________________________
  212. subtree OBJECT-CLASS
  213.     SUBCLASS OF top
  214.     MUST CONTAIN {commonName}
  215.     MAY CONTAIN {manager}
  216.     ::= oc-subtree
  217.  
  218. ___________________Figure_2:__Representing_Subtrees____________________
  219.  
  220.  
  221. CN=Bells, OU=Computer Science,
  222. O=University College London, C=GB
  223.  
  224.  
  225. Suppose that the MTA needs a table mapping from MTA Name to bilateral
  226. agreement information of that MTA. The table might be named as:
  227.  
  228. CN=MTA Bilateral Agreements,
  229. CN=Bells, OU=Computer Science,
  230. O=University College London, C=GB
  231.  
  232.  
  233. To represent information on the MTA:
  234.  
  235. CN=Q3T21, ADMD=Gold 400, C=GB
  236.  
  237.  
  238. There would be an entry in this table with the Relative Distinguished
  239. Name of the table entry being the Distinguished Name of the MTA being
  240. referred to.  The MTA Bilateral information would be an attribute in
  241. this entry.
  242.  
  243.  
  244. 2  Representing Subtrees
  245.  
  246. A subtree is similar to a table, except that the keys are constructed
  247. as a distinguished name hierarchy relative to the location of the
  248. subtree in the DIT. The subtree effectively starts a private ``root'',
  249. and has distinguished names relative to this root.  Typically, this
  250. approach is used to associate local information with global objects.
  251. The schema used is defined in Figure 2.  Functionally, this is
  252. equivalent to a table with distinguished name keys.  The table
  253. approach is best when the tree is very sparse.  This approach is
  254. better for subtrees which are more populated.
  255.  
  256.  
  257. Kille                                  Expires:  January 1994   Page 4
  258.  
  259.  
  260.  
  261.  
  262. INTERNET--DRAFT             Representing Subtrees            July 1993
  263.  
  264.  
  265. The subtree object class defines the root for a subtree in an
  266. analogous means to the table.  Information within the subtree will
  267. generally be defined in the same way as for the global object, and so
  268. no specific object classes for subtree entries are needed.
  269. For example consider University College London.
  270.  
  271.  
  272. O=University College London, C=GB
  273.  
  274. Suppose that the UCL needs a private subtree, with interesting
  275. information about directory objects.  The table might be named as:
  276.  
  277.  
  278. CN=private subtree,
  279. O=University College London, C=GB
  280.  
  281. UCL specific information on Inria might be stored in the entry:
  282.  
  283.  
  284. O=Inria, C=FR,
  285. CN=private subtree,
  286. O=University College London, C=GB
  287.  
  288. Practical examples of this mapping are given in [2].
  289.  
  290.  
  291. References
  292.  
  293. [1] The Directory --- overview of concepts, models and services,
  294.     December 1988. CCITT X.500 Series Recommendations.
  295.  
  296. [2] S.E. Kille. MHS use of the directory to support MHS routing,
  297.     April 1992. Internet Draft.
  298.  
  299.  
  300. 3  Security Considerations
  301.  
  302. Security considerations are not discussed in this INTERNET--DRAFT .
  303.  
  304.  
  305. 4  Author's Address
  306.  
  307.  
  308.     Steve Kille
  309.  
  310. Kille                                  Expires:  January 1994   Page 5
  311.  
  312.  
  313.  
  314.  
  315. INTERNET--DRAFT             Representing Subtrees            July 1993
  316.  
  317.  
  318.     ISODE Consortium
  319.     PO Box 505
  320.     London
  321.     SW11 1DX
  322.     England
  323.  
  324.     Phone:  +44-71-223-4062
  325.  
  326.  
  327.     EMail:  S.Kille@ISODE.COM
  328.  
  329.     DN: CN=Steve Kille,
  330.     O=ISODE Consortium, C=GB
  331.  
  332.  
  333.     UFN: S. Kille, ISODE Consortium, GB
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363. Kille                                  Expires:  January 1994   Page 6
  364.  
  365.  
  366.  
  367.  
  368. INTERNET--DRAFT             Representing Subtrees            July 1993
  369.  
  370.  
  371. A  Object Identifier Assignment
  372.  
  373.  
  374. _______________________________________________________________________
  375. mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
  376.           enterprises(1) isode-consortium (453) mhs-ds (7)}
  377.  
  378. tables OBJECT IDENTIFIER ::= {mhs-ds 1}
  379.  
  380. oc OBJECT IDENTIFIER ::= {tables 1}
  381. at OBJECT IDENTIFIER ::= {tables 2}
  382.  
  383. oc-subtree OBJECT IDENTIFIER ::= {oc 1}
  384. oc-table OBJECT IDENTIFIER ::= {oc 2}                               10
  385. oc-table-entry OBJECT IDENTIFIER ::= {oc 3}
  386. oc-text-table-entry OBJECT IDENTIFIER ::= {oc 4}
  387. oc-distinguished-name-table-entry  OBJECT IDENTIFIER ::= {oc 5}
  388.  
  389. at-text-table-key OBJECT IDENTIFIER ::= {at 1}
  390. at-text-table-value OBJECT IDENTIFIER ::= {at 2}
  391. at-distinguished-name-table-key OBJECT IDENTIFIER ::= {at 3}
  392.  
  393.  
  394. _______________Figure_3:__Object_Identifier_Assignment_________________
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416. Kille                                  Expires:  January 1994   Page 7
  417.